En Allianz-app bygget etter styleguiden: forsiden med polisekort, hurtighandlinger og fanelinje

Tre skjermer i wireframe: rotskjerm, pushet skjerm og et overlegg

En hjem-fane med skjermer stablet bak hverandre, nummerert etter hvordan man kommer dit

Oppsettet for splash screen, med logoområde og valgfri avsender

Rutenett over toppbarens varianter med profil, søk, varsler og innstillinger

Kontekst

Hvordan får man 177 apper til å føles som ett selskap?

Allianz er et føderalt selskap, som vil si at hver avdeling i de over 60 landene de opererer i, har mye autonomi. For et av verdens største selskaper er dette nyttig, fordi de kan tilpasse seg lokale realiteter, som konkurransebildet, juridiske krav og kulturelle forskjeller. Problemet oppstår når man likevel vil fremstå som et samkjørt selskap.

Siden hver avdeling hadde forskjellige ressurser og strategier for sine digitale flater, ble resultatet et enormt spenn i kvalitet på tvers av de 177 appene, noe som ikke holder mål i en digital verden. Hvor mye man sentraliserer og hvor mye man delegerer, er for Allianz et evig spørsmål, men i en stadig mer digital verden ble det klart at det trengtes globale standarder for digitale flater.

Prosjektet hadde fire rammer, og hver av dem forklarer et valg jeg tok.

Ingen felles fasit

Det finnes ingen samlet sannhetskilde for hvordan apper skal se ut og oppføre seg. Apples Human Interface Guidelines er ikke spesifikke nok, og Material Design bruker andre ord for de samme tingene. Moderne apper lager egne mønstre gjennom flittig testing og utforsking, uten å skrive ned hva de er og når de gjelder. Designsystemer som Carbon og SAP Fiori er skreddersydd til sine egne produkter.

Valget: Jeg kartla mange kilder, i stedet for å velge én.

Frivillig å bruke

Hvert appteam har autonomi til å velge bort guiden. Den måtte derfor være så elegant og dekkende for teamenes behov at den ble et opplagt valg, framfor å finne opp hjulet på nytt.

Valget: Jeg holdt guiden konsis.

Kort tid

Guiden skulle være på plass før et stort nytt appprosjekt startet.

Valget: Skrivebordsresearch framfor brukerinvolvering. Det var ingen naturlig plass for brukere i tidslinjen, og de var heller ikke det sentrale i dette prosjektet.

177 apper

Det var langt flere apper enn noen hadde full oversikt over, også kunden. Det fant jeg ut underveis. Med så mange apper må man være sikker på hva de er, for å forstå behovene til organisasjonen.

Valget: Kartleggingen ble fundamentet. Det var også en fordel: behovene lå allerede synlige i appene, så jeg kunne samle skjermbilder av flytene og se hva det allerede var designet for.

Prosessen

Kartlegge behov → Bygge et språk

Prosjektet dreide seg først og fremst om grundig og bred kartlegging, og deretter vid designutforskning. Jeg var den eneste som fant råd og retning, og beslutningene gikk gjennom en design director i Kurppa Hosk, og designsystemansvarlig og teknisk leder i Allianz globalt.

Prosessen: fem kilder samles i en syntese av krav, deretter designutforskning, og til slutt en felles styleguide

Klart problem

Styleguide

Selv om det var mange apper, var behovet veldig snevert. Alle appene skulle stort sett gjøre det samme: samle forsikringer, vise dashbord for formuesforvaltning, og huse forsikringsskjemaer. Det gjorde det mye lettere og nyttigere å lage en konsis styleguide.

Så lagde jeg egne kategorier og måter å tenke på, og testet dem ved å designe skjermer og flyter med dem. Der de ikke holdt, skrev jeg dem om, og mye av det jeg designet, ble aldri med. Fordi Allianz også opererer i arabiske land, sjekket jeg i tillegg mønstrene for språk som leses fra høyre.

Plassholder: skjermdesign som ikke ble med

Styleguiden handler om hvordan apper settes sammen, ikke om hva brukerne skal få til, så den lar seg ikke teste på brukere. Den hviler i stedet på skjønn, og på konvensjoner millioner allerede bruker hver dag.

The nativity dilemma

Lik opplevelse, ikke likt utseende

Allianz vil være frampå og brukervennlige. For kunden betydde konsistens i utgangspunktet at alt så likt ut og oppførte seg likt på tvers av plattformer, og to design er dobbelt så mye å vedlikeholde.

Jeg mente at målet ikke er å være lik på tvers av plattformer, men å tilby lik opplevelse. Det er to forskjellige ting, fordi brukere på iOS og Android har forskjellige forventninger, og en forskjellig idé om hva premium og frampå ser ut og føles som. Likhet for likhets skyld er ikke et mål.

Kostnaden er reell, men to design er normen, og for et av verdens største selskaper kjøper det tillit og kvalitetsoppfatning hos brukerne. Kunden kjøpte argumentet.

Derfor lener guiden seg inn i hver plattform. På iOS anbefales Liquid Glass på navigasjonen, selv om apper bygget i Flutter bare får det via tredjepartsløsninger. Flat A1-styling er et gyldig alternativ, og Android skal ikke etterligne det. Teamene kan fortsatt bygge seg rundt dette, men det er tungt, og sterkt frarådet.

Resultat

Levert og i bruk

Resultatet er en styleguide på 3 400 ord, som danner rammene for hvordan apper kan bygges, og hvordan designsystemet bør utvides når teamet får tid til det. Å få den så kort var en jobb i seg selv: utkastene til bare fem av kapitlene var på over 6 600 ord. Motion, ikonbruk og forhåndsdefinert typografi valgte jeg bort, fordi det ble for granulært med så mange land og situasjoner. Motion var nærmest å komme med, men monnet mindre enn det guiden dekker.

Styleguiden er levert og i bruk. Det er et internt dokument i et stort konsern der ting tar tid, så endringene synes ikke i appene ennå. Effekten synes uansett ikke i én app, men i hvor fort teamene kan bygge.

En styleguide er statisk, mens plattformene og produktene den styrer, endrer seg hele tiden. Vi foreslo å gjøre den levende, med tilbakemeldinger fra teamene som bygger med den. Allianz valgte det bort. Neste gang ville jeg bygget tilbakemeldingen inn i leveransen fra start, i stedet for å foreslå den til slutt.